1. Technical Field
The present invention relates generally to collaborative computing in the form of a computer conference and, particularly, to enabling at least two computer users to collaborate by sharing a single application. Sharing an application means that the application is running on a particular computer and that each computer user who is a conference participant sees the application (user interface, text, graphics, windows, etc) on their particular computer, and each participant may provide input to the application (in the form of keystrokes, mouse, dials, tablets or other input devices) from their particular computer when the application is listening to them, i.e. they have the `input focus`.
More specifically, the present invention relates to an anarchic method to dynamically switch the input focus in a conference enabled application between designated participants.
2. Description of the Related Art
The AIXPersonal graPHIGS (TM) Programming Interface is an implementation of the PHIGS three dimensional graphics standard. A graPHIGS application can be viewed as having three layers as shown in FIG. 1. The application makes subroutine calls on the graPHIGS shell to perform graphical operations such as creating a window or a graphical object. The graPHIGS shell communicates with the graPHIGS nucleus on behalf of the application. The graPHIGS nucleus manages workstation/graphical resources on behalf of the application. The application and the graPHIGS shell are always in the same execution thread. The graPHIGS shell may connect to a `private` graPHIGS nucleus in the same execution thread, communicating via subroutine calls. Or, the graPHIGS shell may be connected to a `remote` graPHIGS nucleus in a separate execution thread, communicating via a network protocol such as GAM or TCP/IP sockets, an example of which is illustrated in FIG. 1. The graPHIGS nucleus may actually reside on the local computer or on a remote computer connected via the network.
A graPHIGS application makes subroutine calls to graPHIGS, known as application program interface (API) calls, to display graphics on the user's workstation. Sharing a graPHIGS application among a set of users on multiple workstation requires that each user on each workstation be able to see and to interact with the same application view. In a conferencing arrangement consisting of two or more participants, each graPHIGS API call is performed on each participants workstation, enabling each user to see the same view of the application. The following is a brief description of a particular method to broadcast graPHIGS API calls to multiple graPHIGS workstations.
A prerequisite to broadcasting the graPHIGS API calls to multiple users is the ability to take a graPHIGS function call made by the application and repeat this function called multiple times, once on each participants computer. GraPHIGS applications use the graPHIGS API, which consists of a collection of subroutines. Each subroutine call collects parameters provided by the application and passes them to a single graPHIGS function of the form: EQU AFMAIC (AAB, APIcode, APIparms)
where AAB is an application anchor block used to store graPHIGS data structures, APIcode is an integer identifying the current API call, and APIparms is an array of pointers to the API call parameters. Each parameter referred to in APIparms is either an INPUT or OUTPUT parameter; there are no INOUT parameters in the graPHIGS API.
The application anchor block is provided by the application and is initially empty. The anchor block provides a context for the execution of graphics API calls. API calls may change the state of the data structures within the anchor block. Applications may use one or more anchor blocks at a time, providing multiple context for the execution of graPHIGS API calls. The execution of an API call using one anchor block has no effect on any other anchor block.
The graPHIGS API is enabled for conferencing N users through the following steps:
1. Intercepting each graPHIGS API call at the afmaic level.
2. Associating N anchor blocks AAB (1 . . . N) with the application's anchor block AAB where each anchor block AAB {i} is associated with user {i}.
3. Invoking afmaic on each AAB {1 . . . N}. The effect is to repeat the graPHIGS API call on each user's anchor block, thereby repeating the function call, once for each user.
By enabling the graPHIGS shell to connect to a graPHIGS nucleus on a remote machine, the application may run on machine A while displaying geometry on machine B. By combining this graPHIGS remote nucleus capability with the ability to repeat API calls to multiple users, it is possible to broadcast graPHIGS API calls to the multiple users, each on a separate computer. For example, assuming there are three network users, illustrated in FIG. 2, who each want to share an application, three anchor blocks simulate three complete graPHIGS shells. Each simulated graPHIGS shell is connected to a graPHIGS nucleus on a user's workstation. Any graPHIGS API call invoked by the application is performed on each graPHIGS shell and the effect, if any, of the API call is reflected on the displays of all the remote workstations.
Certain graPHIGS API calls must be performed on all of the simulated graPHIGS shells, while others must be performed on only one shell. Any graPHIGS API call may be classified into one of three categories. The first is broadcast, which includes API calls that must be performed on all shells. Examples include creating a workstation (a window) or drawing a line. The second category is inquiry, which query the state of the graPHIGS shell or nucleus and return the result to the application. Inquiry API calls should be sent to a single privileged graPHIGS shell/nucleus so that a sequence of inquiries return consistent results over time. The third category is input, which includes API calls that return user input to the application. These input API calls must be sent to the graPHIGS shell corresponding to the user who is currently interacting with the application. The user, or more specifically, the graPHIGS shell/nucleus currently interacting with the application is called the `input focus`. Over time the input focus will change according to an input arbitration mechanism.
This classification of broadcast, inquiry and input API calls ensures that graPHIGS API calls behave properly. Those functions with side effects such as drawing geometry or creating windows are performed on all users' graPHIGS nuclei. Those functions that return input are performed on the user's nucleus that is currently providing input. Those functions that return the result of software or hardware capability are performed on only one machine to ensure consistency.
The preceding does not describe a method of selecting a user to be the input focus, nor does it describe how or when to change the input focus from one user to another. Accordingly, what is needed is a method to dynamically switch the input focus from a participant A to a participant B when both A and B are ready. The switching of the focus must not require intervention by the application, nor may it harm the application with inconsistent input.